Fix/version week - #533

Optimization(zh-Hant): 贊助卡片改為橫式排版，與右欄其他卡片對齊更好看
Optimization(en-US): the sponsor card now row-aligns with the right column

The More page will lead the version card with a stable anchor number: a
release names itself and a snapshot names the release it builds toward.
That value — the newest v* tag, v stripped — now rides every build the
same way the label does, through version.sh, the generated build info,
and CI's dart-define.

New(zh-Hant): 更多頁上方卡片重新設計，版本以漸層數字顯示，pre-release 顯示上一版主版本號
New(en-US): the More hero cards go flat, and the version card leads with a gradient major.minor named after the last release

Fix(zh-Hant): 修正圖層時間軸在某些時區會顯示成 UTC 時間
Fix(en-US): map timelines now show frame times in the device's local time instead of UTC

The version card's big number is the train (26.1) — the release a snapshot
is cut toward — not the previous release tag. version.sh already derives
it; this replaces the last-release pipeline with a train pipeline end to
end: script output, generated build_info, the AppBuild surface, and the
dart-defines CI stamps.

No user-visible change yet; the card itself lands in the next commit.

The support, Discord and announcement cards each centred their row, so
every icon and label started where its own row's text happened to end.
Now they all start at the same left margin and the trailing arrows sit at
the same right margin.

Fix(zh-Hant): 修正「更多」頁上方三張卡片的圖示與文字起點對齊
Fix(en-US): align the icons and text of the three hero cards on the More page

The version card now reads 26.1 first — the train every build rides — and
a snapshot names itself beside it in smaller print (26w34a). Both are
larger than before so the number is the thing the eye lands on.

New(zh-Hant): 「更多」頁版本卡改以版號 26.1 為主，測試版同時標示完整版號
New(en-US): the version card on the More page leads with 26.1 and shows the full snapshot name beneath it

New(zh-Hant): 更多頁英雄區加入伺服器狀態卡，並縮小版本卡
New(en-US): Add the server-status card to the More hero block and slim the version card

New(zh-Hant): 新版號 26.2.1 的版型只顯示 26.2
New(en-US): A three-part release (26.2.1) advertises as 26.2; the patch stays in the label

New(zh-Hant): 版本卡片徽章加上 build 日期
New(en-US): The More page badge shows the day the build was cut

New(zh-Hant): 版本徽章右側顯示 build 日期
New(en-US): The version badge now carries the day this build was cut

New(zh-Hant): 繁體贊助相關文案改用「支援」
New(en-US): Traditional-Chinese support copy now reads 支援, not 支持

New(zh-Hant): README 新增 Android 測試版與 iOS TestFlight 連結
New(en-US): README now links the Android testing track and the iOS TestFlight beta

A merge commit is invisible to the commit gate — `check_commits.sh` walks with
`--no-merges`, because a merge message is generated rather than written — so
anything that arrives through one is never judged. A branch that is behind is
a different hole: the gates that passed describe a tree nobody will ever have.

The message gate also now walks the branch's own tip rather than the checked-out
merge commit, and takes the base ref through the environment: a pull request
from a fork carries whatever branch name its author chose, and that was being
pasted into the shell.

Optimization(zh-Hant): App 日誌改用內建畫面，多了搜尋、等級篩選與分享
Optimization(en-US): the log screen gains search, level filtering and sharing

The hand-rolled layout existed to dodge an overflow in `TalkerScreen`'s header,
because an overflow is logged and the screen rebuilt on every line — a loop
that ended in a hang. That loop is cut where it starts now, so rebuilding the
screen ourselves bought nothing and cost the search, the filter, the sharing
and the settings that come with the real one. Three l10n keys went with it.

The row ceiling drops from 20000 to 5000 and moves into the insert's own
transaction. It was only applied by the hourly sweep, and a fault that logs
every frame writes faster than any sweep runs — so the table could not be
bounded between them, which is exactly the case the ceiling is for.

Fix(zh-Hant): 修正日誌頁把同一個錯誤不斷印到主控台，回放的紀錄也不再遺失等級
Fix(en-US): stop the log screen reprinting one fault forever, and keep replayed levels

Two faults, both mine, both from the change that stopped the screen freezing.

The repeat check sat *after* `FlutterError.presentError`, so suppression
covered the log, the crash report and the database but not the terminal: the
same fault printed every frame while the stored record stayed clean, which is
exactly how it was described — the data was fine and the console was unusable.
It is checked first now, and the first few still print, because that dump is
what makes a layout fault findable.

And a replayed line was titled `stored`, which threw away the level it was
written with. Talker colours a card and the level filter narrows by `logLevel`,
so every line read back out of the table was uncoloured and unfilterable — the
two things the screen is read with.

Fix(zh-Hant): 修正日誌頁的清除只清畫面，重開又整份回來
Fix(en-US): clearing the log no longer leaves everything to come back on reopen

The screen's clear button calls `talker.cleanHistory()`, which empties the
in-memory list and nothing else. The screen replays the `logs` table on every
visit, so everything came straight back from a table the button never touched —
the one thing it is pressed for is the one thing it did not do.

Talker's history is an interface, and this app already supplies its own, so
clearing it now clears the table with it.

Fix(zh-Hant): 修正日誌頁上方等級篩選器把回放的紀錄全算成 undefined
Fix(en-US): the level filter counts replayed lines under their level again

The screen groups its filter chips — and their counts — by `TalkerData.key`,
and colours a card by the same value. Not by the level, and not by the title.
A replayed line carried neither, so every stored line of every level collapsed
into one chip labelled `undefined`, uncoloured.

`Log.replay` also fills in the title and pen from that key, which is what the
logger does on the way past and what skipping it skipped.

Fix(zh-Hant): 修正開啟日誌頁會把本次啟動的紀錄擠掉，順序也錯亂
Fix(en-US): opening the log no longer pushes out the running session's lines

Talker's history appends and evicts from the front, so replaying a day of
stored lines pushed the live session out — `DPIP starting up` among them — and
left the older lines sitting where the newer ones should be. Reading 1000 into
a history that holds exactly 1000 made it certain.

That is backwards twice over. The stored log is on disk and can be read again,
the running session cannot; and lines older than everything in memory belong in
front of it, not appended after. Replay now inserts at the front and only into
free space.

Fix(zh-Hant): 修正啟動早期的紀錄從來沒被存下來，當機時最該看的那幾行都不見
Fix(en-US): fix the launch's own log lines never being stored, the ones a crash needs

Merging the stored log into what was already in memory produced a fault every
time it was touched: a loaded line evicting the running session, older lines
sitting after newer ones, a duplicate left behind on each visit. All of it came
from keeping two records and reconciling them.

There is only one record. Every line is persisted, so memory held nothing the
table did not — except the lines from before the database opened, which is the
gap that made replacing unsafe and is a hole in its own right: `DPIP starting
up` is logged at bootstrap.dart:111 and the store opens at :139, so everything
that explains a crash during launch was in memory and nowhere else. Those are
copied in now, and the screen loads the table over the top instead of merging.

Optimization(zh-Hant): 日誌的等級標籤改成大寫，一眼看得出哪一行不是 INFO
Optimization(en-US): log lines are tagged INFO / WARN / ERROR, readable at a glance

A level is a label, not prose, and it reads as a column when a hundred lines
are scanned for the one that is not `INFO`. `WARN` rather than `WARNING` keeps
the five that matter within a character of each other, so the messages after
them line up.

Display only. The `level` column still stores the enum's own name, so a stored
line parses back to the level it was written with.

Optimization(zh-Hant): 主控台的日誌改成一則一行，不再有框線與跑掉的顏色碼
Optimization(en-US): console logs are one plain line each, without borders or stray colour codes

The default logger draws every entry inside a box and paints it with ANSI
escapes. Neither survives the trip: `flutter run` prefixes each line with
`flutter: `, so a three-line box becomes three prefixed lines around one
message, and the escapes arrive as the literal text `^[[38;5;4m` because
nothing on that pipe reads them. What was meant as colour read as noise.

Colour was never delivered rather than lost — `enableColors` can go back on if
the output is ever read somewhere that renders it.

Optimization(zh-Hant): 主控台的等級標籤可以上色，用 --dart-define=DPIP_LOG_COLOR=true 開啟
Optimization(en-US): the console level tag can be coloured with --dart-define=DPIP_LOG_COLOR=true

A choice rather than a detection, because it cannot be detected: the bytes are
written on the device and read in whatever window is attached to `flutter run`,
which the app cannot see. VS Code's Debug Console prints ANSI literally — that
is where `^[[38;5;4m` came from — and its integrated terminal renders it. Same
build, different window.

`TalkerLogger` forces `ansiColorDisabled = false` in its constructor whatever
stdout is, which is why the escapes were emitted to a pipe that could not read
them at all. Off by default now, and only the tag is painted when it is on: a
fully coloured line is harder to read than a plain one, and a leak then costs
one short token instead of the whole line.

Fix(zh-Hant): 修正 iOS 上開啟主控台顏色只會多出跳脫字元，看不到顏色
Fix(en-US): enabling console colour on iOS added escape characters instead of colour

The flag was written as a choice because a terminal's capability cannot be
detected from inside the app. On iOS there is nothing to choose: the platform's
log path escapes the escape character itself, so a terminal that does support
ANSI still receives a backslash followed by the sequence and prints it. That is
flutter/flutter#20663, and it is why turning the flag on looked like it did
nothing but add noise.

That part *is* detectable, so it is detected. Elsewhere the flag still means
what it said.

Optimization(zh-Hant): 新增 tool/colorize_logs.sh，在終端機端替日誌上色
Optimization(en-US): add tool/colorize_logs.sh, which colours the log in the terminal

The app writes plain text and should keep doing so. On iOS an escape sequence
cannot survive the trip: the platform's log path escapes the escape character
itself, so a terminal that fully supports ANSI still receives a backslash
followed by the sequence and prints it — flutter/flutter#20663.
`dart:developer`'s `log` does deliver them, but truncates anything past ~128
characters to `<collected>`, and the long lines are the diagnostic ones, so it
buys colour with the content.

A pipe has neither problem, because the bytes are written by the terminal that
knows whether ANSI works — and it turns itself off when the output is not one.
It drops the `flutter: ` prefix too, which is a terminal's width back.

    mise exec -- flutter run | tool/colorize_logs.sh

Optimization(zh-Hant): 新增 tool/run.sh，一個指令跑起來就有上色的日誌
Optimization(en-US): add tool/run.sh so one command runs the app with a coloured log

    tool/run.sh -d "iPhone 17 Pro"

Hot reload still works. The tool reads `supportsColor` from stdout and its
keystrokes from stdin, and a pipe only touches the first — what is lost is
flutter's own colour and its progress spinner, which are redraw sequences a
pipe turns into litter anyway.

`pipefail` is the part a wrapper like this usually gets wrong: without it the
pipeline reports the colouriser's status, a failed build exits 0, and the
wrapper hides the thing it wraps. A test builds a stub that exits 7 and checks
the wrapper does too.

Fix(zh-Hant): 修正結束執行時出現 Broken pipe 的未處理例外
Fix(en-US): fix the unhandled Broken pipe exception when a run is stopped

Ctrl-C reaches every process in the foreground group, so the filter died first
and `flutter run` — still shutting down, still printing — wrote into a closed
pipe and reported EPIPE as an unhandled exception, stack trace and all. The
filter now ignores the interrupt and reads until its stdin closes, which is
when the writer has genuinely finished.

`tool/run.sh` is also the only supported way to start the app now, and a debug
build says so when it was started any other way. Both alternatives work and
both are wrong invisibly: a bare `flutter run` resolves whatever SDK the
shell's PATH cached — `mise activate` does not refresh it when mise.toml
changes — and the log arrives uncoloured either way.